Let's not use any 'dummy' values. Cert-manager has a list of prerequisites documented. Use real requirements.

Help me understand the value that this provides.
What is the output of running this when:

1. There's a failure
2. It's successful

Is this meant to check formatting of the preflights?
If something is formatted poorly won't it be hard to debug since you concat them all into a temporary file? It seems like running this on each chart individually would be much more straight forward since you would know which chart failed and the line numbers on errors (does it provide those?) would line up.

Great catch on the failure, I separate the preflight call now to detect if there's failure.

I can't imagine we actually want to support setting an ENV for DRY_RUN which is very specific to this one task and not something you likely want set permanently.

yes I think the variable is already scoped locally to the helm-preflight task only.

I committed the suggestion but it looks like it is not valid Taskfile syntax

err:  "default" is not a valid variable type. Try "sh", "ref", "map" or using a scalar value
file: /Users/gerard/dev/platform-examples/applications/wg-easy/Taskfile.yaml:180:9
  178 |     vars:
  179 |       DRY_RUN:
> 180 |         default: false
      |         ^
  181 |     cmds: 
  182 |       - |

Ok so the syntax wasn't correct but it can still be done can't it?

vars:
  DRY_RUN: false

Or something like that?

I'm asking why you're explicitly making a dynamic variable when you don't need it to be dynamic. I think you're copying a pattern that we setup when we were setting global variables and importing environments but I don't think it is necessary here.

Maybe I'm just misunderstanding Taskfile and this isn't possible or the dynamic nature of using "{{.DRY_RUN}}" provides some value that I'm not aware of. Does including "{{.DRY_RUN}}" provide some value or is that the only way to set a variable?

What do you think about using the pattern Chuck introduces in POVs to keep the preflight valid yaml.

apiVersion: v1
kind: Secret
metadata:
  name: cert-manager-preflights
  labels:
    troubleshoot.sh/kind: preflight
type: Opaque
stringData:
  preflight.yaml: |-
{{ .Files.Get "templates/preflight.yaml" | indent 4 }}

Then you would put: at applications/wg-easy/charts/cert-manager/templates/preflight.yaml

apiVersion: troubleshoot.sh/v1beta2
kind: Preflight
metadata:
  name: cert-manager-preflights
spec:
  analyzers:
    # https://github.com/cert-manager/cert-manager/blob/master/deploy/charts/cert-manager/README.template.md#prerequisites
    - clusterVersion:
        outcomes:
          - fail:
              when: "< 1.22.0"
              message: The application requires at least Kubernetes 1.22.0, and recommends 1.25.0.
              uri: https://cert-manager.io/docs/installation/helm/#prerequisites
          - warn:
              when: "< 1.25.0"
              message: Your cluster meets the minimum version of Kubernetes, but we recommend you update to 1.25.0 or later.
              uri: https://cert-manager.io/docs/installation/helm/#prerequisites
          - pass:
              message: Your cluster meets the recommended and required versions of Kubernetes.

Finally, I think you would need to in the .helmignore:

templates/preflight.yaml

This allows you to edit the preflight as an actually valid yaml file. If you needed to adjust the preflight based on helm values in the future you could just as easily use an include and change the preflight to a .tpl and it's fully helm temptable. I'm not sure if .Files.Get or include is better but at least in this example you don't actually need the templating so I just went for the Files.Get pattern.

This might even simplify the preflight checking you're doing with dry run because you can call the file directly without having to go through the helm chart.

I think that is great improvement using both Files.Get or include. I opted in for include now as from Helm docs

Some files cannot be accessed through the .Files object, usually for security reasons.
Files in templates/ cannot be accessed.
Files excluded using .helmignore cannot be accessed.

We will have to create new folder on same level with templates which would unnecessarily complicate our directory structure. Also include allows future preflight checks to access Helm values more easily.

Ok so the syntax wasn't correct but it can still be done can't it?

vars:
  DRY_RUN: false

Or something like that?

I'm asking why you're explicitly making a dynamic variable when you don't need it to be dynamic. I think you're copying a pattern that we setup when we were setting global variables and importing environments but I don't think it is necessary here.

Maybe I'm just misunderstanding Taskfile and this isn't possible or the dynamic nature of using "{{.DRY_RUN}}" provides some value that I'm not aware of. Does including "{{.DRY_RUN}}" provide some value or is that the only way to set a variable?